Universal Plug and Play (UPnP) provides a network architecture that facilitates adding and removing devices from a network. For instance, the UPnP architecture allows a user to simply “plug” a new device into a network coupling; thereafter, the network will automatically determine the new device's characteristics and subsequently coordinate interaction between this new device and others in the network based on the determined characteristics. The UPnP architecture is particularly well suited for networks associated with a local setting, such as a home, a business, a school, etc. (Note that the term “Universal Plug and Play” derives from functionality provided in the earlier developed device Plug and Play (PnP); device PnP provides a flexible technique for automatically adding and removing peripherals to a standalone computer device, such as a PC).
FIG. 1 presents high level information regarding an exemplary UPnP architecture 100. By way of overview, the UPnP architecture 100 includes a plurality of devices (e.g., devices 102, 104, and 106) and control points (e.g., control points 108 and 110) coupled together via a network 112.
The UPnP devices (102, 104, and 106) can include a variety of electronic devices. Exemplary devices include computers of all types, CD/DVD players/jukeboxes, TVs, VCRs, MP3 players, stereo systems, electronic picture frames (EPFs), various types of still and video cameras, and so on. More specifically, a so-called UPnP device conceptually defines a container that can include actual devices, services, etc. A service, in turn, defines various functions performed by a UPnP device that are made available to other UPnP devices. For instance, one exemplary service might pertain to a chronological function provided by a clock. In general, a service models its functionality using state variables and exposes various actions associated with the model to other UPnP devices. In the exemplary case of FIG. 1, the UPnP device 102 includes an actual device 114 that provides a service 116. UPnP device 104 includes an actual device 118 that provides services 120 and 122. UPnP device 106 includes an actual root device 124 that provides services 126 and 128. The root device 124, in turn, includes an embedded device 130 that provides a service 132.
The network 112 can couple the devices (102, 104, 106) together using the Transmission Control Protocol and the Internet Protocol (TCP/IP). The network 112 can also freely draw from a number of other standard protocols, such as Hypertext Transfer Protocol (HTTP), Simple Object Access Protocol (SOAP), General Event Notification Architecture (GENA), and so on. The network 112 can be physically implemented using a variety of hardwired and/or wireless communication mechanisms, such as phone lines, power lines, Infrared Data Association (IrDa), Ethernet, Radio Frequency (RF) coupling, and so on.
Finally, the control points (108, 110) define agents that can discover and control other UPnP devices. A UPnP device may itself include one or more control points integrated therewith.
FIG. 2 illustrates conventional functions performed by the UPnP architecture 100 arranged in hierarchical layers. An addressing function 202 pertains to procedures whereby devices and control points receive addresses to interact with the network 112. More specifically, a device or control point can receive an address from a Dynamic Host Configuration Protocol (DHCP) server or using an Auto IP assignment procedure (e.g., if no DHCP server is available). The Auto IP procedure provides a technique for intelligently selecting an IP address from a set of private reserved addresses.
A discovery function 204 pertains to procedures whereby devices advertise their services to control points. Devices can perform this advertisement by sending out a multicast variant of HTTP (i.e., HTTP-MU). A control point subsequently responds using HTTPU (i.e., a unicast variant of HTTP). The discovery function 204 makes use of General Event Notification Architecture (GENA) and Simple Device Discovery Protocol (SSDP) to carry out the above-noted exchange between UPnP devices and control points. Further, a newly added control point can also search for UPnP devices and services coupled to the network.
A description function 206 pertains to a procedure whereby a control point that has discovered a UPnP device can determine more information regarding the UPnP device. The UPnP device responds by sending information to the control point, where such information is presented, using the extensible markup language (XML). Such information defines details regarding the type of UPnP device (e.g., manufacturer, model name and number, serial number, etc.), the services it offers, uniform resource locators (URLs) for interacting with the device, and so on.
A control function 208 involves transmitting a control message from the control point to the UPnP device. The UPnP architecture 100 uses SOAP to transmit this message. SOAP messages contain action requests. The UPnP device executes the action specified in the SOAP message and then responds to the control point. The response contains action-specific values or fault codes.
An eventing function 210 pertains to a procedure whereby a control point monitors events associated with services provided by the UPnP architecture 100. More specifically, a service can send an event when its model changes state. The process of “publishing” these state changes is referred to as eventing. The control point can subscribe to receive various events by sending a subscription message to a service of interest.
Finally, a presentation function 212 entails retrieving a page of information from a UPnP device using a presentation URL associated with this UPnP device. The control point can initiate the presentation process by issuing an HTTP GET request to the UPnP device. The presentation function 212 allows a user to view the status of the device and/or control the device.
The UPnP Forum's web site (i.e., http://upnp.org/) provides more detailed information regarding the UPnP architecture and related topics.
As mentioned above, UPnP devices are commonly used in relatively localized network environments, such as in a home or business. In the home environment, for instance, a network including UPnP devices may interconnect a collection of media source devices and a collection of media rendering devices. An exemplary media source device might comprise a personal computer that stores a collection of music, video, pictures, etc., or may comprise various types of jukebox devices. An exemplary media rendering device might comprise a TV, stereo, personal computer, and so on. A control point (such as a personal computer) can then be used to route resource information from one of the media source devices to a selected media rendering device.
However, existing networks that include UPnP devices do not perform the above-described transfer of resource information in a well-controlled, secure, and responsible fashion. For instance, suppose that a design engineer opts to implement the media server using a personal home computer (PC). In this case, the design engineer may configure the media server such that all of its functionality can be accessed based on a single PC-wide security paradigm. However, as appreciated by the present inventors, a UPnP media server provides a myriad of different functions, and different security levels may apply to these different functions. Therefore, the tactic of applying a single security paradigm to the entire UPnP media server may necessitate selecting a sufficiently low security level for all of the functions provided by the media server so as to ensure access to all of the functions. This has the drawback of potentially jeopardizing the security of critical resources and functions (associated with the media server, the computer system that implements the media server, the that network that the media server is coupled to, and so on), and thus potentially allowing unauthorized entities to gain access to the UPnP media server's private media files. Alternatively, the design engineer may choose to omit certain functions in order to accommodate the use of a single security paradigm. This has the obvious disadvantage of reducing the utility of the media server.
Known UPnP media server solutions also suffer from additional deficiencies and drawbacks. For instance, known UPnP media servers do not provide functionality for accommodating modem computing techniques, such as fast user switching (FUS). The FUS technique provides a convenient technique for switching between different sessions associated with different respective users. For example, the technique allows a first user to connect to a computer and run an application, followed by a second user who runs another application. When the second user connects to the computer, the computer will save an application instance associated with the first user's session. When the first user connects to the computer again, the computer will restore the settings and applications associated with the first user's computer session at the time he or she disconnected. Accordingly, FUS provides functionality that can record multiple application instances associated with any number of respective users. Known UPnP media servers do not provide a mechanism for integrating the FUS technique with their UPnP functionality.
Accordingly, there is an exemplary need in the art to provide a more secure and/or versatile media server for use in networks that include UPnP devices, or analogous computing environments.